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(57) ABSTRACT 

Methods and systems are provided for combining previously 
incompatible network protocols without tunneling. In one 
system, an Internet Protocol ("IP") stack is modified to 
include an IP-compatible datagram component IP' which 
registers a transfer function with an Open Data Interface 
("ODI") component. A NetWare Core Protocol ("NCP") 
stack is similarly modified to include an NCP-compatiblc 
component NCP' which utilizes the registered transfer func- 
tion. The modified protocol stacks provide IP-compatible 
connectivity for NCP services without continually convert- 
ing packets between formats in the manner required by 
protocol tunneling systems. 

20 Claims, 3 Drawing Sheets 
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METHOD AND SYSTEM FOR COMBINING 
COMPUTER NETWORK PROTOCOLS 

RELATED APPLICATIONS 

This application is based on U.S. Provisional Patent 5 
Application Ser. No. 60/028,362 filed Oct. 11, 1996. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document io 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 15 
rights whatsoever. The copy-right owner does not hereby 
waive any of its rights to have this patent document main- 
tained in secrecy, including without limitation its rights 
pursuant to 37 C.F.R. §1.14. 

FIELD OF THE INVENTION 2 ° 

The present invention relates to computer networking 
protocols generally, and more particularly to methods and 
systems for combining previously incompatible protocols so 
that each runs in native format without tunneling. 25 

TECHNICAL BACKGROUND OF THE 
INVENTION 

Computer networking is accomplished using components 3Q 
which include a set of networking protocols. A wide variety 
of protocols are known, and not all combinations of proto- 
cols are compatible with one another. Familiar protocols 
include the Transmission Control Protocol ("TCP"), the 
Internet Protocol ("IP"), the NetWare Core Protocol 
("NCP") (NETWARE is a trademark of Novell, Inc.), the 35 
User Datagram Protocol ("UDP"), the Sequenced Packet 
Exchange protocol ("SPX"), the Internetwork Packet 
Exchange protocol ("IPX"), and many others. 

Protocol stack components interface with one another 40 
through the exchange of data packets and other data/control 
structures such as event control blocks ("ECBs"), and 
through calls to one another's routines. ECBs are described 
in "ODI Specification Protocol: Stacks and MLIDs (C 
Language)," which is commercially available from Novell, 45 
Inc. of Orem, Utah. Protocol incompatibilities manifest 
themselves as a lack of space, encoding differences, or a 
difference in functionality in the structures and/or routines 
that are available for one protocol to communicate with 
another protocol. For instance, IPX packets use 10-byte 50 
source and destination addresses while the IP packet format 
only allocates 4-byte addresses. Thus, full IPX addresses are 
incompatible with IP addresses. 

Such incompatibilities limit the availability of protocol 
functionality. For instance, NCP defines a wide variety of 55 
routines for using and managing information in networks, 
including file system services, directory services, printing 
services, and security services. But these services rely on 
lower-level services provided by IPX. Thus, network users 
whose system does not support IPX generally do not have go 
access to NCP services. Stated differently, NCP and IP are 
incompatible in conventional systems (as are SPX and IP, 
NCP and UDP, SPX and UDP, and TCP and IPX). 

"Tunneling" is a process which links otherwise incom- 
patible protocols by continually encapsulating structures 65 
used by one protocol into (more or less) equivalent struc- 
tures used by another protocol. However, this encapsulation 
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process adds significant overhead to the network and also 
introduces the risk that information will be lost or corrupted 
by improper encapsulation or decapsulation. 

To illustrate tunneling, consider first a conventional 
system, containing no tunneling, in which an NCP service 
calls an IPX service. The system does not use IP or any other 
alternative to IPX, but instead relies on IPX. After receiving 
information from the NCP protocol, the IPX protocol would 
call lower level protocols to transmit information over a 
"wire"; as used herein, "wires" include one or more links 
such as copper wire, cable, optical fibers, microwave 
transceivers, satellites, and other transmission media. At the 
other end of the wire, a second instance of IPX would 
receive the information and pass it upward in turn to a 
second instance of NCP. 

Now assume that transmission over the wire is to be 
accomplished using IP. In a tunneling system, both IP and 
IPX are used, even though IP and IPX duplicate much of 
each other* s functionality from a network architecture point 
of view. The first NCP instance hands information to the first 
IPX instance, as before. However, in the tunneling system 
the first IPX instance has been modified so that it calls an 
encapsulation routine from an encapsulation module instead 
of calling the lower level protocols. The encapsulation 
routine encapsulates the information, which is in IPX 
format, creating a packet that fits IP format and then calls IP 
(hence "tunneling" into IP through IPX). IP transmits the 
information over the wire (with the assistance of lower level 
protocols as is usual for IP) to a second IP instance. The 
second IP instance hands the received information to a 
second conversion module. The conversion module converts 
the information back into IPX format and passes it to a 
second instance of IPX. Finally, the second IPX instance 
passes the information up to a second instance of NCR 

In view of the inefficiencies and risks of tunneling and the 
benefits of connectivity, it would be an advancement in the 
art to provide a system and method for placing otherwise 
incompatible network protocols in communication with one 
another without tunneling through one protocol into another 
protocol that duplicates much of the first protocol's network 
functionality. 

It would be an additional advancement to provide such a 
system and method which reduces or eliminates the use of 
conversion routines. 

It would also be an advancement to provide such a system 
and method which do not require changes in packet formats 
or other data/control structures that are already in wide use 
by numerous individuals and institutions. 

Such a method and system for combining network pro- 
tocols is disclosed herein. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides a method and system for 
combining previously incompatible network protocols with- 
out tunneling. In one embodiment of the invention, an IP 
stack is modified to contain an IP-compatible component IP 
which registers a predetermined and relatively small set of 
identifiers and service routines with a Link Support Layer 
("LSL") in an Open Data Interface ("ODI") component. An 
NCP stack is similarly modified to include an NCP- 
compatible component NCP' which utilizes the registered 
identifiers and routines. The ODI component underlies both 
IP' and NCP' and performs low-level services such as 
transport of data packets over the wire. 

In this embodiment, no version of IPX is required 
(although IP, IP, and IPX can run concurrently or in turns on 
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the same system if desired, with each handling their respec- FIG. 8 is a diagram illustrating the data and header 

tive network connections). A registered transport function portions of an Ethernet packet created in a system according 

replaces a corresponding transport function of IP. Thus, a to the present invention, 
system of the present invention may operate in the following 

manner: 5 DETAILED DESCRIPTION OF THE 

(a) an IP' protocol stack is provided at a source, and a PREFERRED EMBODIMENTS 

second IP stack is provided at a destination; The present invention relates to a method and apparatus 

(b) NCP' protocol stacks are provided at the source and for combining previously incompatible computer network 
destination; protocols such as NCP and IP, or other previously incom- 

(c) each IP' registers a transport function with an ODI 10 patible groups of protocols, without tunneling. The network 
component; protocols are suitable for use on a computer network. The 

(d) each NCP obtains the address of the registered computers on the network may be workstations, laptop 
transport function so it can call the registered function computers, disconnectable mobile computers, fi e servers, or 
directly a comD1Datlon thereof. The network may include one or 

, v '. . , 15 more LANs, wide-area networks, Internet servers and 

(e) an application or other entity at the source requests an ^ m a 00llllrfnadcm lhereof . 

NCP service (the service is preferably identical with ^ _ , . , „ 

the corresponding NCP service, at least from the point u 0ne of ,he ^Pf* networks suited for use with 

of view of applications and users); ' he P resen ' ' "ventum * generally at 100 m FIG. 1. 

. . _ ... , „ ,„ In one embodiment, the network 100 includes Novell Net- 

(f) m the course of servicing the request, the source NCP 20 m (NETWARE ^ a 

invokes the registered transport function (rather than registered trademark of Novell, Inc.). In alternative 

calling an 1FX transport function, as NCP would in a embodiments> the network 100 indues NetWare Connect 

conventional system without lr or in a tunneling sys- Services, VINES, Windows NT, LAN Manager, or LAN- 

tern which uses both IP and IPX); ^ netWQrk operatiflg system software ( yiN£S fc a tfade _ 

(g) the source IP' uses the registered transport routine in 25 mark of Banyan Systems; NT and LAN MANAGER are 
place of the corresponding transport routine that would trademarks of Microsoft Corporation; LANTASTIC is a 
be used by IP, manipulates the data appropriately, and trademark of Artisoft). The network 100 may include a local 
passes the data over the wire to the destination IP' using area network 102 which is connectable to other networks 
ODI or other low-level support as needed; and ^ 104, including other LANs or portions of the Internet, 

(h) at the destination, the process is reversed, with IP' through a gateway or similar mechanism. "Internet" as used 
passing data to NCP' using the registered transport herein includes variations such as a private Internet, a secure 
function. Internet, a value-added network, a virtual private network, 

The features and advantages of the present invention will an extranet, or an intranet, 
become more fully apparent through the following descrip- 35 The network 100 includes several servers 106 that are 
l i° n - connected by network signal lines 108 to one or more 


BRIEF DESCRIPTION OF THE DRAWINGS 


network clients 110. The servers 106 and the network clients 
110 may be configured by those of skill in the art in a wide 

To illustrate the manner in which the advantages and variety of ways to operate according to the present inven- 

features of the invention are obtained, a more particular 40 tion - The servers 106 may be configured as file servers, as 

description of the invention summarized above will be given Internet servers, as directory services providers, as software 

with reference to the attached drawings. These drawings component servers, or as a combination thereof. The servers 

only provide selected embodiments of the invention and are 106 and clients 110 may be uniprocessor or multiprocessor 

not therefore to be considered limiting of its scope. In the machines. 

drawings: 45 Suitable network clients 110 include, without limitation, 

FIG. 1 is a diagram illustrating a computer network personal computers 112, laptops 114, and workstations 116. 

suitable for use with the present invention. The signal lines 108 may include twisted pair, coaxial, or 

FIG. 2 is a diagram illustrating the network architecture of °P lical fiber cabIes > tele P h °ne lines, satellites, microwave 

a conventional NCP/IPX system. Components closer to the rela y s ' modulaled AC P° w er lines, and other data transmis- 

user appear near the top of the diagram, while those closer 50 sion "wires" known to those of skill in the art. In addition to 

to the wire appear near the bottom of the diagram. the network client computers 110, a printer 118 and an array 

. ,. .„ . t , ... . r or disks 120 are also attached to the network 100. Although 

HI G. 3 is a diagram illustrating the network architecture of 4 . . . , , . . A 6 , 

. & . . 6 ..™„ nv , rp/i.-i /in particular individual and network computer systems and 

a conventional system running NCP/IPX and ICP/IP. r . , . c . ... . v , J ... 

. ( . . r components are shown, those of skill in the art will appre- 

FIG. 4 is a diagram illustrating the network architecture of 5J cialc lhal the prcscm invcntion also works with a varicl of 

a system which employs conversion routines to tunnel other nctworks and computers. 

through IPX to IP. ^ e servers 106 and the network clients 110 are capable 

FIG. 5 is a diagram illustrating the network architecture of of ^ floppy tapc drivcS) ical dHvcs Qr Qthcr 

3 Sy x^ m , a . CCOrding 5° the P rcsenl inventlon whic h mdudes mcans t0 rcad a storage mcdium U2 A suitable st 

an NCP /IP protocol stack. 60 medium U2 iMcs a magnetiCj optical( or olher 

FIG. 6 is a diagram illustrating the network architecture of computer-readable storage device having a specific physical 

a system according to the present invention which includes substrate configuration. Suitable storage devices include 

an NCP7IP protocol stack in combination with NCP'/IPX* floppy disks, hard disks, tape, CD-ROMs, PROMs, RAM, 

and TCP/IP* protocol stacks. and other computer system storage devices. The substrate 

FIG. 7 is a diagram illustrating the data and header 65 configuration represents data and instructions which cause 

portions of an Ethernet packet created in a system which the computer system 100 to operate in a specific and 

tunnels through IPX to IP. predefined manner as described herein. Thus, the medium 
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122 tangibly embodies a program, functions, and/or instruc- 
tions that are executable by the servers 106 and/or network 
client computers 110 to perform network protocol interface 
and usage steps of the present invention substantially as 
described herein. 

To better illustrate the invention, conventional systems 
are shown in FIGS, 2 through 4. Such systems either lack 
functionality provided by the present invention or introduce 
inefficiencies by utilizing steps or structures not required by 
the present invention. For instance, the system 200 shown in 
FIG. 2 includes an NCP protocol component 202, and an 
SPX protocol component 204 on top of an IPX protocol 
component 206, which in turn interfaces with an Open 
Datalink Interface component 208. The system 200 does not 
provide NCP component 202 functionality to users whose 
connectivity relies on IP connectivity because IP is not 
supported. In particular, machines which are connected only 
over the Internet cannot access and manage each other's 
resources using NCP components 202 when those machines 
have the network architecture shown in FIG. 2. 

FIG. 3 shows a system 300 which includes the system 200 
plus an additional protocol stack comprising a TCP protocol 
component 302, an IP protocol component 304, and an 
optional UDP protocol component 306. However, simply 
adding the TCP/IP protocol stack does not solve the prob- 
lem. Machines which have the architecture shown in FIG. 3 
can communicate with one another over the Internet using 
their respective TCP/IP stacks, but still cannot access and 
manage each other's resources using their NCP components 
202. Only when connectivity is provided by the IPX com- 
ponent 206 can two such machines employ NCP services. 

1\vo machines in a system 400 which have the architec- 
ture shown in FIG. 4 can utilize Internet IP connectivity to 
support NCP services with respect to one another, but only 
by continually converting between IPX and IP using a 
conversion component 402. Reliance on this conversion 
module 402 decreases efficiency and increases the risk to 
data. Each act of conversion 402 requires time, processing 
power, and memory, and occurs at both the source and 
destination. 

FIGS. 7 and 8 illustrate another aspect of the inefficiency 
by contrasting the extra headers created when tunneling with 
the lack of such headers when the present invention is used. 
FIG. 7 shows an Ethernet packet 700 created in a system 
such as that shown in FIG. 4. The packet 700 contains a 
Ethernet header 702, an IP header 704, an IPX header 706, 
and NCP header 708, and a data portion 710. For clarity, 
only headers are shown in the Figures, but those of skill in 
the art will understand that data packets may also contain 
corresponding trailers. Both the IP header 704 and the IPX 
header 706 are needed, even though IP and IPX are both 
datagram services, because the system tunnels through IPX 
to IP. 

FIG. 8 illustrates an Ethernet packet 800 created in a 
system according to the present invention, such as the 
system 600 in FIG. 6. The packet 800 still contains the 
Ethernet header 702 and the data 710. But instead of the 
three headers 704, 706, and 708 for IP, IPX, and NCP, 
respectively, the packet 800 contains only two headers: an 
IP header 802 and an NCP' header 804. Advantageously, 
unlike the packet 700 the packet 800 requires only one 
datagram service layer header. 

The two headers 802, 804 have the same format as 
headers used in conventional systems such as the systems 
shown in FIGS. 2 and 3, but may be modified according to 
the teachings of the present invention. In one embodiment, 


the packet headers 802, 804 have the same offsets for all 
fields, and the same field contents for all fields, as the 
conventional headers 704, 708. In another embodiment, the 
packet headers 802, 804 have the same offsets for all fields, 

5 and the same field contents for almost all fields, as the 
conventional headers 704, 708, with the difference being 
that one or more identifiers (such as a socket number, port 
number, address, connection identifier, or protocol 
identifier) in the packet 800 contains a value that is recog- 

10 nized as valid only in systems configured according to the 
invention. 

Embodiments 500, 600 of the present invention are fur- 
ther illustrated in FIGS. 5 and 6. Machines thus configured 
may be servers, clients, or both. These embodiments allow 
NCP's functionality, in the form of NCP* components 502, 
to run in any protocol stack which provides datagram 
services, such as a stack that includes the IP-compatible IF 
component 504. The NCP' component 502 is preferably 
implemented in a manner making it compatible with the IPX 
component 206, with an IPX-compatible IPX' component 
604, with a UDP-compatible UDP' component 602, and/or 
with IP' component 504. The IPX' component 604 is pref- 
erably compatible with the SPX component 204, and the IP 
component 504 is preferably compatible with the TCP 
component 302. 

NCP has few requirements from the protocol stack and if 
these functional requirements are met it can be run over any 
protocol stack. These requirements are: 

1. datagram service; 

2. identification of the maximum amount of data that can be 
sent in one datagram on the wire; and 

3. suitable receive and transmit Application Program Inter- 
faces ("APIs"). 

In order to access the datagram service layers that the 
NCP component 502 will run over, such as the IP* and UDP' 
components 504, 602, a registration mechanism is provided. 
The mechanism allows access to a given datagram service 
transport layer independently of alternatives to that layer 
(e.g., access to IP regardless of whether IPX is present). 

One method of the present invention locates protocol 
stack configurations through the Link Support Layer 
("LSL") of the ODI component 208. Although some data- 
gram service layers might not register with the LSL, the IPX 
and IP protocol stacks normally do register, so they can be 
used as alternatives to one another according to the present 
invention, without tunneling. Other protocols can also be 
made interchangeable by designing a registration process for 
their datagram service layers with the underlying protocol 
50 stacks and then making that information available to the 
previously incompatible higher layers. 

In one embodiment, the following structure "abstracts" 
the IP/IPX datagram service layer for use by the NCP 
component 502: 


typedef struct -PROTOCOL_SWITCH_ { 

PROT ID *PSw_dgscrviccID; 

PSWSTAT CPSW_tx_func) (ECB -pEcb); 

PSWSTAT (*PSw_tx_dclay_fuac) (ECB *pEcb); 

PSWSTAT CPSW_raw_u tunc) (ECB *pEcb); 

PSWSTAT (• PSw_app_skt_reg) 

(UINT32 'sktnumber, 
struct ResourccTagStructure *RTag, 

void Capp_8kt_caUback) (ECB -pEcb); 

PSWSTAT (*PSw_app_skt_dereg) (UINT32 •sktnumber); 

PSWSTAT (•PSw_queue_resource) (ECB *pEcb); 
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-continued 


-continued 


INFO_BLOCK -PSw_ioctl; 

PRarocou_swrrcH; 


with additional functionality including the following: 


//PSWSTAT is ENUM of possible correct and error return codes from 
//protocol switch structure functions, 
typedef en urn _PSWSTAT_ { 

PSWSTAT_SUCCESFULL - 0, 

PSWSTAT_BAD_COMMAND - -127, 

PSWSTAT_BAD_PARAMETER - -126, 

PSWSTAT_DUPLICATE_ENTRY = -325, 

PS WSTAT_FAIL - - 1 24, 

PSWSTAT_ITEM_NOT_PRESENT - -123 

PSWSTAT; 
PSw_dgscrviceID 

Datagram service layer identifier, matches identifier 
used by datagram service layer to identify itself to 
underlying protocol stack and the underlying protocol 
stack's type in the form <yyyy xxxx xxxx> where <yyyy> 
is the protocol identifier and ocxxxx xxxx> is the 
datagram service layer identifier (in hexadecimal), 
e.g. SPX over IPX 8137 0000 0005 
UDP over IP 0800 0000 0011 

(IP Next Header value of 11 
for UDP) 

Note, where the datagram service identifier is zero, 
PSw_dgserviceID refers to the underlying protocol 
stack, e.g. <8137 0000 0000> refers to the protocol IPX 
only. 

PSWSTAT (*PSW_tx_func) (ECB -pEcb); 

where pEcb is an Event Control Block ("ECB") to 
transmit immediately. 

PSWSTAT (*PSW_tx_delay_func) (ECB *pEcb); 

where pEcb is an ECB to transmit with delay, e.g. hold 
the send for possible later sequential packets. 

PSWSTAT (*PSW_raw_tx_func) (ECB *pEcb); 

Where pEcb is an ECB to transmit immediately which has 
had all fields that would normally have been set by the 
protocol already set. i.e. everything already formed 
and ready to be transmitted via the Link Support Layer. 

PSWSTAT (*PSw_app„skt_reg) (UINT32 *sktnumber, 

void (*app_skt_callback) 
(ECB -pEcb); 

where 

sktnumber is a pointer to the socket number to 
register. Note that "socket" means the identifier used 
for transmission and reception of packets, which is 
called a "socket number"* according to IPX terminology 
and a "port number" according to UDP terminology. 
Rtag is a pointer to a Resource Tag structure to track 
resources used. 

app_skt_callback is a call_back function for specified 
pEcb. 

This function registers an application distinguishing a 
routable entity with the protocol stack, e.g. socket. 
PSWSTAT CPSw_app_skt_dereg) (UINT32 *sktnumber); 

where sklnumber is a pointer to the socket number 

to de register. 

This function de registers an application distinguishing o 
routable entity with the protocol stack, e.g. socket. 
PSWSTAT (-p5w_queue_resource) (ECB "pEcb) 

where pEcb pointer to an ECB to register for application 
route entity. 

This function registers a resource per application route 
entity, e.g. post listen ECB on a socket basis. 
INFO_BLOCK •PSW_ioctl; 

where PSw_ioctl is a pointer to an INFO BLOCK. 
This function is used to obtain an INFO_BLOCK which 
allows for access to control information from the datagram 
service layer. 

INFO_BLOCK - PSw_LayerControllnfoBlock - 
{ PSw_NUM_API, 
void (••) (void'*)) &PSwAPL_Array 


where void (*PSwAPI_Array[]) - 
5 (void (") (void)) PSw_GetMaXTSDU 

}; 

#dcfine PSw_NUM_API 1 /• currently only 1 IOCtl V 
PSWSTAT PSw_GetMaxTSDU (UINT32 BoardNumbcr, 
UuNT32 'Size, 
PROT_ID •dgservicelD); 

10 Input: BoardNumber 

Board number that the datagram service layer 

is using. 

dgserviccID 

pointer to a datagram service layer 
identifier, matches identifier used by 
35 datagram service layer to identify itself to 

underlying protocol stack. 
Output: Size 

pointer to buffer to return maximum size of 
data that may be sent atomically using the 
underlying Protocol layer. 
Return: PSWSTAT 
Remarks 

Obtains the maximum size of data that may be sent atomically 
using the underlying Protocol layer with the specified 
board. 


20 


25 


35 


55 


60 


The various datagram service layers operating on top of a 
protocol stack may be found by querying the protocol 
stack's IOCtl ProtocolManagement function with a Man- 
agement ECB whose ECB_protocolID field contains the 
<GETDSL> value (Get Datagram Service Layers). The 
information returned in the Management ECB files is as 
follows: 


ECB_Status 


ODISTAT_SUCCESSFUL 


ODISTAT_OUT_OF ..RESOURCES 


40 


ECB_Data Length 


45 


50 


ECBFragment[0j.FragmentAddress 


Buffer contains information 
requested. 

Buffer provided in ECB is 
insufficient to return 
information. ECB Field 
ECB_Data Length 
contains size required to 
return information desired. . 
Number of bytes of informa- 
tion copied into buffer if 
successful, otherwise zero. 
If the value ODISTAT_ 
OUT_OF_RESOURCES 
is returned, the field 
contains the size of buffer 
required to return information 
desired. 

pointer to buffer containing 
datagram service layer 
information if successful. 


The format of information contained in the ECBFragment 
buffer after a successful call to obtain a Protocol Stack 
Datagram Service Layer Informational Element is: 


typedef struct _PS_TL_INFO_ELEMENT_ { 

MEON_STRING -PS_TL_Info_Name; 
PROTOCOL_SWrrCH -PS_TL_Info_S witch; 

} PS_TL_INFO_ELEMENT, 
where 

PS^TL_Info_Name 
65 pointer to MEON_STRING (ASCIIZ) containing name of 

datagram service layer, e.g. TCP. 


03/16/2004, EAST Version: 1.4.1 


US 6,229,809 Bl 


10 


-continued 


PS_TL_Info Switch 

pointer to datagram service layer Protocol Switch 
structure, register with the protocol stack when 
the datagram service layer was installed. 


Additional Management ECB commands for protocol 
stacks allow the various datagram service layers operating 
on top of a protocol stack to locate needed protocol 
information, such as a Network Identifier for the host 
system. The protocol stack's IOCtl ProtocolManagement 
function is queried with a Management ECB whose ECB_ 
protocolID field contains the <GETNID> value (Get Net- 
work Identifiers). The access is as above but the format of 
information contained in ECB buffer when successful is as 
follows: 


typedef struct _PS_NID_INFO_ELEMENT_ { 


UI1STT32 
UINT32 
UINT8 

PS_NID_INFO_E LEM ENT, 
where 

PS_NID_ProtBoard 


PS_NID_Size 


PS_NID_Identifier 


PS„NID_ProtBoard; 

PS_NID_Size; 

PS_NID„ldentifier{]; 


Contains any internal Board 
number that the Protocol is using, 
-1 if unused. 

The size of the buffer described by 
PS_NID_Identifier. If 
ODISTAT_OUT_OF_ 
RESOURCES is returned the field 
ECB„Data Length contains the 
size of the buffer required 
to return the Network Identifier 
Buffer to containing the Network 
Identifier used by the protocol 
to identify the host system the 
protocol is residing on. 


In order to enable higher level protocols (such as NCP' 
502) to locate the PROTOCOL_SWITCH structure for 
datagram service layers (such as IP' 504), the datagram 
service layers register the PROTOCOL_SWITCH structure 
with the underlying protocol stack (such as ODI 208) when 
the datagram service layers are first installed. Registration of 
other functions and values is already part of the initialization 
of some protocol stacks, such as UDP's registration with IP. 
The underlying protocol stack provides the following API in 
order to accomplish this registration process. Use of an 
equivalent de-registration process is optional. 


PSWSTAT C<Protocol Name>RegisterDsLayer 

(MEON_STRING •TLName, 
PROTPOCOL_SWiTCH •TLSwiich); 

where 

TLName is a pointer to MEON_STRING (ASCJJZ) containing name 
of datagram service layer, e.g. TCP; 

TLSwitch is a pointer to datagram service layer Protocol Switch 
structure; and 

examples include CIPxRegisterDS Layer, CI PRegisterDS Layer 
functions. 


In summary, the present invention provides a novel 
approach which permits the use of previously incompatible 
computer network protocols, such as NCP and IP, with one 
another without requiring tunneling, conversion, or the 
presence of alternative protocols. In one embodiment, NCP 
and IP implementations are modified such that although they 
present the same functionality and interface to application 
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and ODI-level components, they now communicate directly 
with one another without the use of IPX or TCP. 

Although particular methods embodying the present 
invention are expressly illustrated and described herein, it 
will be appreciated that apparatus and article embodiments 
may be formed according to methods of the present inven- 
tion. Unless otherwise expressly indicated, the description 
herein of methods of the present invention therefore extends 
to corresponding apparatus and articles, and the description 
of apparatus and articles of the present invention extends 
likewise to corresponding methods. 

The invention may be embodied in other specific forms 
without departing from its essential characteristics. The 
described embodiments are to be considered in all respects 
only as illustrative and not restrictive. Any explanations 
provided herein of the scientific principles employed in the 
present invention are illustrative only. The scope of the 
invention is, therefore, indicated by the appended claims 
rather than by the foregoing description. All changes which 
come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

What is claimed and desired to be secured by patent is: 

1. A method for transmitting data between a source 
computer and a destination computer in a computer network, 
comprising the steps of: 

providing a datagram service layer protocol stack at the 
source and providing a second datagram service layer 
protocol stack at the destination; 

providing a connection -oriented layer protocol stack at 
the source and providing a second connection-oriented 
layer protocol stack at the destination, the datagram 
service layer protocol stacks and the connection- 
oriented layer protocol stacks on at least one of the 
source computer and the destination computer defining 
previously incompatible protocols using at least one of 
the following protocol pairs: an NCP protocol with an 
IP protocol, an SPX protocol with an IP protocol, an 
NCP protocol with a UDP protocol, an SPX protocol 
with a UDP protocol, and a TCP protocol with an IPX 
protocol; 

registering at least a transport function of each datagram 
service layer protocol stack in a register; 

requesting a service of the connection-oriented layer 
protocol stack at the source; and 

avoiding tunneling while servicing the request at least in 
part by invoking the registered transport functions. 

2. The method of claim 1, wherein the connection- 
oriented layer protocol stack includes an NCP-compatible 
component. 

3. The method of claim 2, wherein the requested service 
appears to an application program to be identical with a 
corresponding NCP service in a network which is not 
configured to operate according to said method. 

4. The method of claim 1, wherein the datagram service 
layer protocol stack includes an IP-compatible component. 

5. The method of claim 1, wherein the register resides in 
an ODI component. 

6. The method of claim 1, wherein each connection- 
oriented layer protocol stack obtains an address of the 
registered transport function so it can call the registered 
function directly. 

7. The method of claim 1, wherein the connection- 
oriented layer protocol stack on at least one of the source 
computer and the destination computer includes an NCP- 
compatible component, and the datagram service layer pro- 
tocol stack on that computer includes an IP-compatible 
component. 
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8. The method of claim 7, wherein the source NCP- means, and protocol stacks provide data transmission 
compatible component invokes a registered IP-compatible between the two computers without protocol tunneling, 
transport function in place of an IPX transport function. 13. The system of claim 12, wherein the datagram service 

9. The method of claim 8, wherein the requested service component is compatible with at least one of IP and UDP. 
appears to an application program to be identical with a 5 14, The system of claim 12, wherein the connection- 
corresponding NCP service in a network which is not oriented component is compatible with at least one of NCP 
configured to operate according to said method. anc j 

10. The method of claim 8, wherein the register resides in 15 ^ lem of claim u wherdn the registration 

an ODI component. - . c . 1 

„ „ « . . . , T on •. 1 means registers the memory address of an executable 

11. The method of claim 8, wherein each NCP-compatible 10 • . ■ .i_ , _ i j iL 

...... c . r . instruction in the transport function, and the invocation 

protocol stack obtains the address of the registered - . r . . 

f D , -* a * * j I. t . • . 1 means transfers control to an instruction at that address. 

IP-compatible transport function and calls the registered A ,. „ 

function directly 16 A com P uter storage medium having a configuration 

12. A computer system of at least two conneclable that represents data and instructions which will cause at least 

computers, each computer comprising: 15 a P 0rtl0n of a computer system to perform method steps for 

a nmPMcnr. transmitting data, the method steps comprising the steps of 

a processor, ^ ^ 

a memory accessible to the processor; 1? Tfae slorage medium of ^ u wherein ^ method 

registration means for registering a transport function that steps comprise the steps of claim 7. 

transmits data in data packets which contain an 2Q 18. The storage medium of claim 16, wherein the method 

IP-compatible header and which lack an IPX- st ^ tfae st of claim 9 

compatible header, and the data packets also contain an 19 ^ medium of daim ^ method 

NCP-compatible header; stcps comprise ^ steps of daim 3 
invocation means for invoking the transport function; and 20, The storage medium of claim 16, wherein the method 

a protocol stack containing a connection-oriented com- 25 steps comprise the steps of claim 4. 
ponent and a datagram service component, wherein the 

processor, memory, registration means, invocation ***** 


\ 
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